R1 | Planificación muy optimista de las tareas a realizar | 3 | 4 | 12 | 7 | Se hará una reunión con todos los integrantes del grupo, y se decidirá entre todos que tareas eliminar de la planificación |
R2 | Imprevisto de integrante del equipo. No puede hacer sus tareas una semana | 2 | 5 | 10 | 8 | Si la tarea que tiene asignada ese integrante es crítica para el desarrollo de las demás tareas, esta se repartirá entre los demás integrantes del equipo, si no, se le acumulará para la siguiente semana |
R3 | Abandono de integrante del equipo | 5 | 3 | 15 | 9 | Se hará una reunión con todos los integrantes del equipo, y se volverá a hacer una planificación entre los miembros restantes del equipo |
R4 | Adición de nuevos requisitos durante el desarrollo | 4 | 1 | 4 | 12 | Se hará una reunión con todos los integrantes del grupo, y se decidirá entre todos que tareas son más importantes y cuales son menos, para actualizar la planificación |
R5 | Errores de la aplicación no encontrados en la fase de pruebas | 5 | 1 | 5 | 1 | Todos los integrantes harán una realización exhaustiva de pruebas hasta comprobar todas las partes vulnerables del código |
R6 | Análisis de requisitos incompleto y/o erróneo | 5 | 3 | 15 | 13 | Se comprobarán todos los análisis de los requisitos y se volverá a hacer la planificación desde el principio |
R7 | Un integrante no cumple con los mínimos acordados | 4 | 4 | 16 | 14 | Se aplicará lo acordado en el commitment agreement |
R8 | Pérdida de datos o problema en el hardware de un integrante | 2 | 3 | 6 | 10 | Como todo el desarrollo estará subido a GitHub, el integrante deberá volver a configurar su nuevo entorno de trabajo y traerse los datos subidos de GitHub, por lo que perderá lo que no haya subido |
R9 | Cambio en los costes de un proveedor | 4 | 2 | 8 | 11 | Se hará una reunión con todos los integrantes del grupo, y se desarrollará una estrategia de gestión de costes diversificada y que no sea susceptible a un único punto de fallo |
R10 | No hay interés por parte de los clientes | 4 | 3 | 12 | 3 | Se programarán reuniones con aquellos que han mostrado más interés para realizar mejoras en el servicio que incrementen su satisfacción |
R11 | El rendimiento de la aplicación es muy pobre | 3 | 3 | 9 | 2 | Se diseñarán pruebas de carga y periódicamente se programarán reuniones entre los diferentes miembros de los equipos para revisar y evaluar la calidad del código entre todos |
R12 | Nueva aplicación en el mercado muy similar a la nuestra | 4 | 3 | 12 | 6 | Estudiar sus funcionalidades, buscar ventajas y desventajas y comparar con nuestra aplicación. Tener en cuenta buenas funcionalidades que tenga para poder competir en el mercado. |
R13 | Problemas técnicos en el despliegue e integración | 5 | 3 | 15 | 4 | Se tendrá que recortar el alcance, si es necesario, y conseguir que la aplicación se integre frontend y backend despliegue correctamente y pueda ser usada, aunque tenga menos funcionalidades |
R14 | Cupo de horas completo por parte de algunos integrantes del equipo | 3 | 5 | 15 | 5 | Se tendrá que organizar las tareas con un reparto entre menos integrantes (los que tengan horas todavía por cubrir) para que las personas que ya han llegado o le quedan pocas para alcanzar el máximo no tengan que trabajar de más y, por lo tanto, no estar contentos |